We introduced some of the original .NET technologies used to
enable and manage cross-service transactions. A de-facto industry
standard that governs transactions across Web services is
WS-AtomicTransaction, which is an extension of (and provides a set of
transaction protocols for) the WS-Coordination standard. WCF implements
the WS-AtomicTransaction standard and provides a range of
transaction-related features, all of which are encompassed in the System.Transactions namespace .
Note
The WS-Coordination and WS-AtomicTransaction industry standards are described in more detail in the book Service-Oriented Architecture: Concepts, Technology, and Design. The original specifications can be accessed via www.soaspecs.com.
A WCF transaction is carried out by two mechanisms:
transaction manager
resource manager
The resource manager
keeps track of durable or volatile data during the lifespan of a given
transaction. The transaction manager works with the resource manager to
provide a guarantee of atomicity and isolation. In WCF, transactions can
be applied to a service using the ServiceBehavior or OperationBehavior attributes.
Operation Attributes for Transactions
An operation attribute
allows the internal behavior of a transaction to be changed in a manner
that is specific to an operation. In the following code sample, the TransactionFlowOption attribute allows the DebitAccount operation to be invoked inside another transaction. The TransactionScopeRequired operation ensures that if the calling process does not include a transaction, a new transaction will be initiated by the DebitAccount operation.
Example 1.
[TransactionFlow(TransactionFlowOption.Allowed)]
[OperationBehavior(TransactionScopeRequired = true,
TransactionAutoComplete = true)]
void DebitAccount(string accountNo, double amount);
|
Operation attributes used to change the internal behavior of an operation are:
TransactionScopeRequired
Setting the TransactionScopeRequired
attribute to “true” specifies that the operation must be a part of a
transaction. If one is not available, a new transaction will be created.
TransactionAutoComplete
Setting the TransactionAutoComplete
attribute to “true” indicates that the code need not be implicitly told
to abort or commit a transaction. If all the operations in a
transaction complete successfully, the transaction will automatically
commit itself. Setting the property to false requires you to write code
to either commit or roll back the transaction.
TransactionFlow
The TransactionFlow
attribute is used to verify at design-time if an operation will accept
incoming transaction calls. Possible values for this parameter are as
shown in Table 1.
Table 1. Parameter values of the TransactionFlow attribute.
| Parameter Value | Description |
|---|
| Allowed | transactions may flow through to the operation |
| Mandatory | the transaction context created earlier must flow through |
| NotAllowed | transactions created earlier will not flow through to the new operation |
Service Attributes for Transactions
Service attributes allow the internal behavior of a transaction to be changed to better meet your requirements. In Example 2,
if the session in whose context the transaction executes expires, the
transaction will be allowed to complete. The isolation level is set to ReadCommitted, implying that transactions can read volatile data but cannot modify it.
Example 2.
[ServiceBehavior(InstanceContextMode =
InstanceContextMode.Single
ConcurrencyMode = ConcurrencyMode.Multiple,
TransactionAutoCompleteOnSessionClose = true,
TransactionIsolationLevel=
System.Transactions.IsolationLevel.ReadCommitted)]
class AccountService : IAccount
{
...
}
|
Service attributes that can be used to change the internal behavior of transactions include:
TransactionIsolationLevel
In order to maintain data
integrity, a transaction must obtain locks on the data involved with the
transaction. Obtaining locks comes at the expense of concurrency,
thereby preventing other transactions from accessing the same data, and
perhaps associated resources.
When a transaction is
created, the isolation level for the transaction must be specified. This
value determines the level of access that other transactions will have
to volatile data. Transaction isolation level options available to the TransactionIsolationLevel parameter are listed in Table 2.
Table 2. A list of level options for transaction isolation.
| Isolation Level | Description |
|---|
| ReadCommitted | permits
reading committed (permanent) changes to the data by simultaneous
transactions (it also does not permit modifying volatile data) |
| ReadUncommitted | uses the optimistic concurrency model (permits reading and modifying of volatile data) |
| RepeatableRead | permits reading volatile data but does not permit modifying it (but it does permit adding new data) |
| Serializable | permits
reading volatile data, but does not permit either modifying existing
data or adding new data (outcome is similar to transactions executed one
after the other—serially) |
| Snapshot | uses
the optimistic concurrency model and guarantees that all reads made in a
transaction will see a consistent snapshot of the database (the
transaction will be committed only if the updates made in the
transaction do not conflict with any updates made since that snapshot) |
